Hello, Following the bug report at [1], I sent the attached patch to pgsql-bugs mailing list. I'm starting a thread here to add it to the next commitfest. The problem I'm trying to solve is that, contrary to btree, gist and sp-gist indexes, gin indexes do not charge any cpu-cost for descending the entry tree. This can be a problem in cases where the io cost is very low. This can happen with manual tuning of course, but more surprisingly when the the IO cost is amortized over a large number of iterations in a nested loop. In that case, we basically consider it free since everything should already be in the shared buffers. This leads to some inefficient plans, as an equivalent btree index should be picked instead. This has been discovered in PG14, as this release makes it possible to use a pg_trgm gin index with the equality operator. Before that, only the btree would have been considered and as such the discrepancy in the way we charge cpu cost didn't have noticeable effects. However, I suspect users of btree_gin could have the same kind of problems in prior versions. Best regards, [1]: https://www.postgresql.org/message-id/flat/ 2187702.iZASKD2KPV%40aivenronan#0c2498c6a85e31a589b3e9a6a3616c52 -- Ronan Dunklau